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Alarm Lists Synchronization in 
an Alarm Management System 

Background of Invention 

[0001] Field of the Invention 

[0002] The present invention relates to network management, and in particular to 
alarm synchronization between two management network's entities. 

[0003] Description of the Related Art 

[0004] Networks are widely employed nowadays in various areas of activity. Local Area 
Networks (LANs), Wide Area Networks (WANs), Public Local Mobile Networks (PLMN) 
are just a few examples of the uses made of networks for providing new or 
improved services to users and subscribers. In order to insure proper operation, 
each such network is typically monitored by a co-operating management network, 
also called herein an Event Management System (EMS), which acquires and 
processes data related to the activity and/or faults that occur in the Network 
Elements (NEs) of the monitored network. The NEs of the monitored network 
typically issue event notifications for various events (such as alarms) taking place 
in the network, such as for example for call set-ups, radio cell selections, hand-off 
failures in a PLMN, etc. The events are further collected by the EMS and processed 
in a manner defined by the network operator for providing for example indications 
of the level of service quality provided by the monitored network. 

[0005] 

It is a particular function of the EMS to collect, process and display event- 
related information concerning the events and alarms issued by various elements 
of the monitored network. Events and alarms can be issued upon detection or 
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assumption of an error in the monitored network, such as for example the failure 
of a Base Station (BS) transceiver in the PLMN. In such a case, the BS issues an 
alarm notification, which is sent to the EMS. For the purpose of handling and 
managing large quantity of alarms/events notifications from a large 
telecommunication managed network, the EMS may comprise one or more agents 
that are the management network's entities responsible for receiving, processing 
and storing the alarms originating from the NEs of the managed network. For 
example, an Agent may receive the event notifications from the monitored 
network, process them by assigning an event identifier to the received notification 
and store the identified events/alarms in an internal Alarm List (AL). Thereafter, the 
agent can send a notification to one or more Managers, which are another type of 
entities of the EMS that may be dedicated to further processing the alarm 
notifications, such as for example by performing alarm correlation. Alternatively, 
managers may perform, for example, the actual management of the events and 
alarms, i.e. displaying the events and alarms for network administrators, thus 
allowing for example remedial actions to be taken for coping with the original 
malfunction that triggered the event/alarm notification. 

[0006] 

Reference is now made to Figure 1 (Prior Art), wherein there is shown an 

exemplary high-level block diagram of an Event Management System (EMS) 10 

managing a network 1 2, such as for example a PLMN. The managed network 1 2 

may comprise a plurality of NEs 14-50, such as for example a Mobile Switching 

Center 1 (MSC ^ ) 1 4, and MSC 1 6, each comprising a plurality of devices Device 

. , such as for example Device ^ 18 to Device ^ 22 for NE ^ (MSC ) 1 4, and Device 

4 24 and Device ^ 26 for NE ^ (MSC ) 1 6. Each such device may in turn comprise 

one or more components C . , such as for example C 28 to C 34 for the Device 

i 1 4 

1 8, and so on. In such a tree configuration, wherein certain NEs are comprised in 
another NE, itself comprised in yet another NEs, as well as in other types of 
configurations, each NE of the managed network (e.g. MSCs, devices, components, 
etc) may be identified by a Managed Object Instance (MOI), which identification is 
also used in the event or alarm notifications for referring to a particular NE. Upon 
occurrence of a specific trigger, such as for example upon detection of a given 
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malfunction in an NE, an alarm notification is issued by the given NE and is 
transmitted to the agent responsible for the collection of event or alarm 
notifications generated by that specific branch of the managed network 1 2, such as 
for example to Agent 52. Upon receipt of the notification, Agent 52 can perform 
specific actions on that notification, and/or relay the notification to one or more of 
the managers 54 and 56. Thereafter, operators 58 to 62 may access the 
information relating that notification from at least one of managers 54 and 
56.Since an important part of the processing of the EMS is based on alarm 
notifications, which are stored in agent(s) and manager(s) of the EMS, as opposed 
to event notifications that may be deleted upon receipt, it is to be noted that the 
appellation of "alarnrTor "alarm notification" will be used herein, however, without 
any restriction, and being meant to also encompass any kind of event notification. 

[0007] For the purpose of collecting alarm notifications, the Agent i 52 comprises an 
Alarm notification List (AL) stored in a memory, such as for example a database. It 
is to be understood that the alarm notifications collected in the list can be of 
various types, such as for example event notifications related to the normal 
operation of the managed network, alarm notifications related to specific 
malfunctions of the managed network, or any other type of notifications as set by a 
network operator/administrator. The AL content is continuously updated due to, 
for example, the regular occurrence and generation of alarm notifications by NEs, 
the issuance of new alarms, the change in the severity level of existing alarms, etc. 

[0008] In some instances, the Agent 52 may experience AL integrity problems, i.e. the 
AL may become corrupted and is no longer certain to be consistent with the 
current alarm status of the NEs. For example, such instances may arise when the 
communication link between the agent and the monitored NEs is down and some 
alarm notifications may have been lost, or when the data medium of the agent (ex.: 
the hard disk drive) experiences a crash therefore loosing alarm-related data. In 
such instances, the agent needs to rebuild its AL. At that time, the Agent ^ 52 
needs to notify the users of its information, such as for example managers 54 and 
56, about its AL rebuilding process since the users may have duplicated and may 
be using the corrupted and inconsistent copy of the AL. 
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[0009] Although there is no prior art solution as the one proposed hereinafter for 

solving the above-mentioned deficiencies, various methods have been published 
for synchronization of multiple replicated information so that they are identical to 
each other. 

[001 0] The international network management standard 3GPP Alarm Integration 

rd 

Reference Point (IRP), Release 99 and Release 4, by the 3 Generation Partnership 
Project, standardized an alarm synchronization procedure for use between agent 

and manager. With reference being now made to Figure 2 (Prior Art), wherein there 

is shown a high-level flowchart diagram illustrative of the prior art method 

described in the standard for synchronizing an alarm list of two nodes, an agent 

first rebuilds its alarm list, step 55 and, when the agent has rebuilt its alarm list, it 

sends notifications ( NotifyAlarmListRebuilt notifications) to all cooperating 

managers about the AL rebuild fact, step 57. The managers then request (through 

a GetAIarmList operation) the agent to send a copy of the AL, step 59, and the 

agent responds by sending, to each requesting manager, the alarm notifications 

related to the rebuilt AL, step 61. However, this procedure requires extensive 

signalling between the agent and the manager since it implies the use of one 

notification message and one request message before the agent sends the AL copy 

to a manager. Furthermore, upon receipt of the AL rebuilt notifications, the 

managers may request the AL copy at slightly different times. The agent's AL 

content may have changed during this time and therefore the agent needs to 

maintain various copies of the AL to satisfy various managers" requests that may 

come at different times. Maintaining various copies of the AL is a further burden on 

the agent's resources. 

001 ^ The US Patent 5,742,820 discloses a mechanism for synchronizing information 
over a network, and suggests the use of an identifier generated by the original 
database to detect database content consistency. The identifier is sent to systems 
that hold a replicated database. Those systems generate another identifier using 
the replicated database and compare it with the incoming identifier. If the two 
identifiers are different, it is concluded that the databases" contents are also 
different, and the system will initiate the database synchronization procedure. 
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However, this procedure is not adapted for alarm synchronization wherein the 
decision to initiate synchronization is solely taken by the agent. 

[001 2] It would be advantageous to have a simplified yet efficient mechanism for 

event notification list synchronization between an agent and at least one manager 
that solves all the above-identified deficiencies. 

Summary of Invention 

[001 3] It is therefore one broad object of this invention to provide a method, system, 
and first and second network entities for synchronizing alarm lists of two network 
entities of an Alarm Management System (AMS), such as the ones of an agent and a 
manager. According to the invention, the agent loses confidence in its Agent Alarm 
List (AAL) and decides to rebuild at least a portion of the AAL It then notifies its 
cooperating manager(s) via a rebuild notification (e.g. a NotifyFaultyAlarmList 
notification) of the ongoing or impending rebuild process with, preferably, a 
reason (indicating why rebuild is necessary). Upon receipt of the rebuild 
notification, the manager(s) stop(s) the processing of its/their Manager Alarm List 
(MAL) involving alarm notifications from the portion of the AAL being rebuilt, and 
begin(s) to purge these alarm notifications. When the agent completes the rebuild 
of the AAL, it sends to the manager(s) the alarm notifications from the rebuilt AAL, 
preferably using batches having a plurality of alarm notifications, wherein alarm 
notifications of each batch are marked for differentiation. The manager(s) extracts 
the alarm notifications from the batches, restores its/their MAL, and resume 
normal operation. The agent can also use a NotifyAlarmListRebuilt notification for 
sending the rebuilt AAL to the manager(s). 

Brief Description of Drawings 

[001 4] For a more detailed understanding of the invention, for further objects and 

advantages thereof, reference can now be made to the following description, taken 
in conjunction with the accompanying drawings, in which: 

[0015] 

Figure 1 is a high-level block diagram illustrative of an Alarm Management 
System (AMS) where the preferred embodiment of the present invention can be 
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implemented; 

[001 6] Figure 2 is an exemplary flowchart diagram illustrative of a prior art method for 
alarm synchronization; and 

[001 7] Figure 3 is an exemplary nodal operation and signaling diagram of the 
preferred embodiment of the present invention. 

Detailed Description 

[001 8] In accordance with the above-mentioned objects, the present invention 

provides a method, system and corresponding network entities for synchronizing 
the alarm lists of two or more nodes of an Alarm Management System (AMS). In the 
context of the present invention, such nodes of the AMS can be an agent and a 
manager. An agent is a network entity of the AMS responsible for collecting event 
notifications and alarm notifications from managed network elements of a 
managed network, and for storing these alarm notifications pending clearance. For 
this purpose, the agent is typically connected to a plurality of Network Elements 
(NEs) of the managed network. The manager is another network entity of the AMS, 
typically connected to at least one agent and responsible for further processing 
alarm notifications received from the agent(s). While event notifications may be 
received by either the agent or the manager and purged upon receipt, alarm 
notifications are typically stored in internal lists of the agent and the manager, 
since they are typically representative of ongoing malfunctions (active alarms) in 
the managed network, and therefore must typically be stored and further analyzed 
in order to pinpoint and repair those malfunctions. Until the malfunctions are 
corrected, the alarm notifications are typically held in the alarm lists. 

[0019] 

Reference is now made to Fig. 3, which shows an exemplary nodal operation 
and signaling diagram of the preferred embodiment of the present invention. 
Shown in Fig. 3 is an Alarm Management System (AMS) 100 monitoring a managed 
network 1 02 comprising a plurality of Network Elements (NEs), such as for example 
MSC ^ 14, MSC 2 16, and Device ^ 18, which may in turn comprise a plurality of 
devices and components following a tree configuration as shown in Fig. 1 . The AMS 
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1 00 further comprises an agent 52 having an Agent Alarm List (AAL) 1 03 for 
storing alarm notifications received from NEs 14, 16, and 18. The agent 52 may 
communicate through various types of communications links, such as for example 
through a Notification Channel 1 04, with at least one manager of the AMS 1 00, 
such as for example with managers 54 and 56, that may each have a Manager 
Alarm List (MAL) 106 and 108 respectively, for storing alarm notifications received 
from agent 52. It is to be noted that the alarm notifications received by the agent 
52 from NEs 14, 16, and 18 may differ from the alarm modifications received by 
managers 54 and 56 from the agent 52, i.e., first, the alarm notifications sent from 
the agent 52 toward the managers may have been processed by the agent 52 (for 
example, the agent 52 may have correlated a set of alarm notifications received 
-J from network elements, and only send one alarm notifications representative of the 

CP set toward managers), and second, while the agent receives all alarm notifications 

S" : from the NEs, it sends to a particular manager only alarm notifications that 

manager is interested to have. For example, if manager 54 is only interested to 
(p have alarm notifications regarding NE 14, the agent 52 receives alarm notifications 

if a from both network elements 14 and 16, but only relays alarm notifications 

□ originating from NE 1 4 to manager 54. The AMS 1 00 may further comprise an 

J operator 1 10 that can access, view, and analyze the alarm information collected 

O from managers 54 and 56. Although not shown in Fig. 3 for simplification 

pi; 

purposes, it is understood that network elements, agents, managers and operators 
from Fig. 3 are connected with each other through appropriate links, interfaces, 
and filters, as it is known in the art. 

[0020] 

With reference being particularly made to Fig. 3, the process starts when the 
agent 52 loses confidence in its AAL 1 03, action 1 1 2. Various factors may trigger 
action 1 1 2, such as for example when agent 52 detects communication link failure 
between itself and the network element, a crash of the agent's data storage 
medium, a data processing error, or any other malfunction that could result in the 
alteration of the alarm data stored in the AAL 1 03. Action 1 1 2 may as well be 
applied to only a portion 1 1 4 of the AAL 1 03, such as for example to the AAL"s 
portion 1 14 which alarm notifications relate to a specific managed network's part 



Page 7 of 25 



11 6, as shown in Fig. 1 , if, for instance, only that portion 11 4 of the AAL 1 03 lost 
data. Following action 1 12, the agent 52 decides to rebuild the AAL 103, or 
alternatively just the affected portion 114 of the AAL, in action 1 1 8. According to 
the preferred embodiment of the invention, upon deciding to rebuild the AAL, the 
agent 52 sends a Rebuild Notification 1 20 to its cooperating managers 54 and 56 
for informing that it is in the process of rebuilding the AAL 103. The rebuild 
notification 120 may be sent via a notification channel 104, which upon receipt of 
the original Rebuild Notification 1 20, determines that the notification 1 20 is 
directed to both managers 54 and 56, and therefore relays Rebuild Notifications 
1 20" and 1 20"" (which are copies of the Rebuilt Notification 1 20) to manager 54 
and manager 56 respectively. The Rebuild Notifications 1 20, 120", and 120"" may 
comprise i) a Managed Object Instance (MOI) identification 122 for identifying the 
highest ranking NE of the managed network 1 2 whose related AAL portion is being 
rebuilt, and ii) an indication of the reason why the rebuilding is necessary, Reason 
1 1 9. For example, in action 1 1 2, the agent 52 may have decided to only rebuild 
the portion 1 1 4 of the AAL 1 03, the AAL portion 1 1 4 comprising alarm 
notifications originating from the part 1 16 of the managed network 12, as shown 
in Fig. 1 . The reason of the rebuilt may be, for example, a detection of a temporary 
interruption in the link between the Agent 52 and one or more NEs. Therefore, the 
agent 52 notifies the managers 54 and 56 by sending the rebuild notification 120 
comprising the MOI 1 22 identifying the NE 1 4 which is the highest ranking network 
element of the managed network part 1 1 6 and whose related AAL portion 1 1 4 is 
being rebuilt, along with the Reason 1 19 indicative of the temporary interruption in 
the link between the Agent 52 and a given NE. Alternatively, the rebuild notification 
may comprise other kind of indication of the portion of the AAL 103 being rebuilt, 
or no identification at all. Upon receipt of the rebuild notification 1 20" and 1 20"", 
the managers 54 and 56 stop any processing of alarm notifications related to the 
MOI 1 22, and may also begin purging their MAL 1 06 and 1 08 respectively, or at 
least the alarm lists" portions 107 and 1 09 respectively where the alarm 
notifications related to the MOI 1 22 are stored, in actions 1 21 and 1 23. 
Alternatively, upon receipt of the rebuild notifications, the managers 54 and 56 
may mark the concerned alarm notifications for subsequent deletion, log the 
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concerned alarm notifications, inform the Operator 1 10 about the ongoing rebuild 
process of the AAL, or respond with a warning notification to attempts from 
operator 1 1 0 to acknowledge related alarm notifications. In a further alternative, if 
a given manager is set to only receive alarm notifications from one given agent, 
and if the MAL is substantially a copy of the AAL (substantially the same alarm 
information is stored in the AAL and the MAL), or if so desires a particular network 
operator, then the manager may stop all ongoing processing on the MAL, and 
purge the entire MAL. 

[0021] Following the transmission of the rebuild notification 120, the agent 52 

proceeds with a rebuild of its AAL 1 03, or of a portion 1 1 4 thereof, in action 1 24. 
During the rebuilt 1 24, the agent 52 may request and obtain from the related NEs 
all pending alarm notifications. For example, if the agent 52 rebuilds its entire AAL 
103, it requests pending alarm notifications from all related NEs, such as NEs 14, 
1 6, and 1 8 in Figure 3. Alternatively, if for example the agent 52 rebuilds only 
portion 1 14 of the AAL 103, which portion comprises only alarm notifications 
originating from NE 14 and its lower-ranking NEs (part 1 16 of the managed 
network 12, shown in Fig. 1), then the agent 52 only requests pending alarm 
notifications from NE 14 and its lower-ranking NEs. 

[0022] Once the rebuild of AAL 103 is completed, action 126, the agent 52 sends the 

alarm notifications obtained in action 1 24 to the managers 54 and 56, action 1 28. 

The transmission 1 28 may comprise individually sending all the newly received 

alarm notifications, or preferably, sending the alarm notifications in batches of a 

plurality of alarm notifications. For example, the transmission 1 28 may comprise 

one or more alarm batches 1 30 each having a series of alarm notifications 1 34 . , 

i i 

136., and so on, where i designates the number of the alarms batch. The alarm 

notifications carried in the batch 1 30 may be marked (M) as belonging to a given 

i 

batch for differentiating them from alarm records in other batches, and from other 
current alarm notifications being transmitted substantially at the same time to the 
same recipient and not registered in the AAL 103. 

[0023] 

The transmission 1 28 may be effectuated via the notification channel 1 04 
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which relays each alarm batch 1 30 . to the appropriate destination, such as for 

example to managers 54 and 56. Upon receipt of each alarm batch 1 30 , the 

recipient manager extracts the alarm notifications from the alarm batch and 

restores its MAL 1 06 and 1 08 respectively, action 1 40 and 1 42, or the portion 

previously purged in actions 121 and 123. Once all batches of alarm notifications 

are received, the managers can resume normal operation and processing involving 

their respective restored MAL, actions 144 and 146. Following the sending of the 

last alarm batch, the agent 52 also resumes normal operation and processing of its 

AAL 1 03, action 1 50. Particularly, the agent 52 may resume the emission of alarm 

notifications carrying new alarm information that has not been registered in the 

batches 1 30 , in the case such emission was interrupted during the transmission 
i 

of the alarm batches. 

it is also to be noted that various messages may be used for the 
implementation of the present invention, depending upon the communications 
protocol used in a given network, or upon the preference of a given network 
operator. For example, Fig. 4 shows another exemplary nodal operation and 
signaling diagram of the preferred embodiment of the present invention in which 
particular messaging is utilized between the Agent 52 and Managers 54 and 56. 
Shown in Fig. 4 is the same AMS 100 as in Fig. 3 wherein similar elements are 
represented using identical numerals although for simplicity purposes, not all the 
messages and elements of Fig. 3 are represented in Fig. 4. With reference now 
being jointly made to both Fig. 3 and Fig. 4, the rebuilt notification 1 20 shown in 
Fig. 3 may be replaced, as shown in Fig. 4, by a NotifyFaultyAlarmListO notification 
200 that may comprise i) an agent identification 202 indicative that all alarms of 
that given agent may be corrupted. Alternatively, the NotifyFaultyAlarmListO 
notification 200 may comprise the MOI 1 22 as described with reference to Fig. 3. 
The NotifyFaultyAlarmListO notification 200 shown in Fig. 4 may further comprise 
ii) a parameter relating to the reason of the alarm list rebuild decided by agent 52, 
such as Reason 1 1 9. Furthermore, the transmission 1 28 shown in Fig. 3, as well as 
the one or more alarm batches 1 30 . may comprise one or more 
NotifyAlarmListRebuild notification 220, as shown in Fig. 4, carrying at least part of 
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the newly rebuilt alarm list. The NotifyAlarmListRebuild notification 220 of Fig. 4 
may comprise an AlarmlnfoList paremeter 222 carrying the part of, or all of the 
newly rebuilt alarm list, and the reason 1 1 9 indicating why the alarm list has been 
rebuilt. 

[0025] Although several preferred embodiments of the method and system of the 
present invention have been illustrated in the accompanying Drawings and 
described in the foregoing Detailed Description, it will be understood that the 
invention is not limited to the embodiments disclosed, but is capable of numerous 
rearrangements, modifications and substitutions without departing from the spirit 
of the invention as set forth and defined by the following claims. 
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